In a typical modern file system, when a file is initially written to a disk or other mass storage device, the file is divided into equally-sized, logical data blocks, and an attempt is made to write the logical data blocks sequentially and contiguously to the disk or mass storage device. Consequently, when the file is read from the disk or mass storage device, the individual data blocks can be read sequentially, thereby limiting the number of read operations required, which in turn limits the seek time required by the reading component (e.g., disk drive head) to search for and locate the individual data blocks comprising the file. However, over time, as existing files are modified and deleted, and new files are written, the availability of physical contiguous space for writing new files becomes limited. Consequently, files tend to become fragmented. When the files of a file system become fragmented, multiple read operations are required to read the files, and the overall performance of the system suffers.
For a variety of reasons, fragmentation issues may arise with network-based storage systems that implement write anywhere file systems, such as the WAFL® (Write Anywhere File Layout) file system developed by Network Appliance of Sunnyvale, Calif.). Storage systems having file systems with write anywhere capabilities differ from storage systems with more traditional file systems in several respects. First, the write allocation policy of a write anywhere file system is extremely flexible when compared to many traditional file systems. Consequently, the data and/or metadata that make up a particular logical data container (e.g., a file, volume, or LUN) may be written to any location on any mass storage device. For example, when a storage system with a write anywhere file system is writing a file's individual logical data blocks to a disk, the storage system may write the data blocks to any location (e.g., disk blocks) on any disk connected to the storage system. Moreover, when a particular data block of an existing file is modified, the modified data block will not necessarily be written back to the same physical location (e.g., disk block) as the initial data block.
Consequently, with a write anywhere file system, certain classes of workloads are likely to endure performance degradation due to fragmentation issues. For instance, performance levels associated with workloads that are characterized by a large number of random writes followed by a sequential read tend to suffer from fragmentation issues. This may occur, for example, with workloads associated with certain database applications, such as Microsoft® Exchange Server™. For example, during a work day, a large file that makes up an individual user's email mailbox may be modified several times, causing the large file to become severely fragmented. At night, when a verification or backup process is performed on the mailbox file, an attempt is made to sequentially read the file. However, due to the fragmentation caused by the user's activity throughout the day, the system may have a difficult time sequentially reading the mailbox file. Accordingly, reading the fragmented mailbox file is accomplished via a greater number of read operations than would be necessary if the mailbox file was not fragmented.
With a storage system having a traditional file system, a defragmentation application is often utilized to improve the overall performance when the storage system is suffering from a badly fragmented file system. A typical defragmentation application analyzes a fragmented file system to identify files that are fragmented. After identifying a particular file that is fragmented, the defragmentation application attempts to read all of the data blocks comprising the particular file, and to re-write the data blocks to contiguous unallocated disk blocks of the disk or other mass storage device. Consequently, data blocks are physically rearranged. However, the defragmentation operation does not increase the number of allocated disk blocks. For example, for every new disk block allocated, a previously allocated disk block is unallocated and made available.
Traditional defragmentation applications may be ineffective when used with certain network-based storage systems that implement write anywhere file systems. In particular, the WAFL® file system has certain characteristics, which render traditional defragmentation tools less useful. One such characteristic is the ability to create “Snapshots™” when used in conjunction with tools such as SnapDrive™ or SnapManager® for Microsoft® Exchange, both made by Network Appliance, Inc. A Snapshot™ is a form of read-only, persistent, point-in-time image (PPI) of a particular data set, such as a volume, file system, or logical unit number (LUN). The term “Snapshot” is used herein without derogation of any trademark rights of Network Appliance, Inc.
In WAFL®, a file is structured as a tree (hierarchy) of blocks, where the upper level blocks contain meta-data pointing to the lower level blocks that store the actual data. During a Snapshot operation, rather than creating an entirely new tree of blocks to form the Snapshot, only the upper level blocks containing the meta-data are copied, and these copied upper level blocks point to the original lower-level (actual data) blocks. As data in the active file system is modified, the meta-data for the active file system is changed to point to new data blocks, whereas the Snapshot does not change.
FIG. 1 illustrates an example of what occurs during a Snapshot operation. The block labeled “AF” represents a meta-data block (e.g., an inode), for a file that is part of the active file system. The “AF” meta-data block contains meta-data including pointers to four data blocks, “A”, “B”, “C” and “D”, which store the actual data that make up the file. When originally written to disk, the data blocks are written sequentially and contiguously. During a Snapshot operation, the “AF” meta-data block is copied, and a new meta-data block is created, for example, Snapshot meta-data block “SN1”. The Snapshot meta-data block “SN1” includes pointers to the same data blocks (e.g., blocks “A” through “F”), because at that particular point in time (e.g., time=2), the file that is part of the active file system is the same as the file that was captured in the Snapshot operation.
At some later point in time (e.g., time=3), when the file is modified, rather than overwriting the disk block storing data block “C” with a new data block, a new disk block is allocated (e.g., the disk block storing data block “C*”). Accordingly, the pointer in the “AF” meta-data block is updated to point to the new data block “C*”. However, because the data blocks that make up the Snapshot are read-only, the pointer in the Snapshot meta-data block “SN1” continues to point to the original data block “C”. Consequently, the data blocks that make up the file in the active file system (e.g., the bold data blocks) become fragmented. However, because data blocks “SN1”, “A”, “B”, “C” and “D” are part of the read-only Snapshot, those data blocks cannot be moved or rewritten. Therefore, to completely reorder the data blocks that make up the file in the active file system, data blocks “A”, “B”, and “D” need to be copied to a new location, while data block “C*” needs to be relocated. However, this would result in the addition of three new data blocks being allocated. Consequently, a traditional defragmentation application, which might move the data blocks of the active file system to a new location, would be ineffective because it would nearly double the number of allocated blocks.
Furthermore, in an environment with one or more network-based storage systems, there are often multiple file systems involved. For example, each client computer system configured to utilize a storage server may have its own local file system. For example, the local file system on the client may logically map a file's data to logical data blocks, e.g., file block numbers (FBNs). In addition, the storage server may have its own file system that manages the physical mapping of the data to physical storage units (e.g., disk blocks) on the mass storage device. The client's logical mapping of the data blocks will not necessarily coincide with the storage server's physical mapping of the data blocks. Consequently, a defragmentation application executed locally on the client may improve the logical mapping of the data blocks. However, by improving the logical arrangement, the locally executed defragmentation application may cause greater fragmentation of the data blocks as physically stored on the mass storage device. Consequently a defragmentation application executed locally on the client may actually make matters worse in certain instances.